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Abstract 

Message  policy  is  defined  to  be  the  description  of  the  disposition  of  messages  of  a  single 
type,  when  received  by  a  group  of  processes.  Group  policy  applies  to  all  the  processes  of  a 
group,  but  for  a  single  message  type.  It  is  proposed  (lun  group  policy  be  specified  in  an 
expression  which  is  separate  from  the  code  of  the  processes  of  (he  group,  and  in  a  separate 
notation.  As  a  result,  n  is  possible  to  write  policy  expressions  which  are  independent  of 
process  state  variables,  and  as  well  use  a  simpler  control  notation  based  on  regular 
expressions.  Input  protocol,  on  the  fiber  hand,  applies  it'  single  processes  t"i  a  group  as  a 
whole)  for  all  message  types.  I  neapsulation  of  processes  is  presented  with  an  unusual 
emphasis  on  the  transactions  and  resources  which  associate  with  an  encapsulated  process 
rather  than  the  state  space  of  the  process  environment,  t  his  is  due  to  the  notion  of 
encapsulation  without  shared  variables,  and  to  the  association  between  group  policies, 
message  sequences  and  transactions. 
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I.  Int  reduction 


Hie  important  aspects  of  concurrent  language  design  are  communications,  synchronisation 
and  composition  of  processes.  The  liist  two  have  been  eleiisively  si  tidied.  Incusing  n 
questions  such  as  control,  scheduling  and  noiidetomiinisiu.  and  problems  such  as  deadlock 
starvation  and  Fairness.  I  .ess  has  been  said  about  how  complex  processes  may  lie  composed 
From  other  processes,  and  ultimately  From  elementary  sequential  opciaiiom  a, id 
communications  primitives.  This  paper  discusses  grmio  composition  techniques,  and  the 
communications  interfaces  between  processes  when  they  are  organised  as  a  group. 

When  a  message  is  sent  to  a  group  of  processes  as  a  whole,  one  or  more  oi  the  component 
processes  may  receive  it.  We  distinguish  two  aspec  ts  of  group  message  reception  in  systems 
when:  messages  are  typed,  bristly,  processes  are  typical!  >  provided  with  the  means  to  select 
messages  For  reception.  by  scheduling  arrangements  sueli  as  system  queues,  or  by  user  code 
involving  local  variables  to  choose  between  messages  o  different  types.  We  define  group 
input  protocol  to  be  the  input  behaviour  of  the  group  as  a  whole,  for  all  message  types. 
Secondly,  we  define  for  each  message  type,  a  group  policy  which  determines  the  disposition 
of  messages  within  the  group. 

We  shall  argue  that  policies  have  more  to  do  with  the  transactions  handled  by  groups  than 
the  reception  of  individual  messages  by  processes,  and  are  consequently  better  expressed  at 
the  group  level,  because  the  control  of  group  policy  will  be  predicated  on  transaction 
attributes  rather  than  process  variables,  and  because  the  control  issues  seem  simpler,  a 
separate  notation  is  proposed  for  group  policy.  Tin:  notation  also  provides  for  the 
encapsulation  of  one  process  by  another  without  the  use  of  shared  variables. 


2.  Processes  and  Modularity 

I  .anguage  proposals  for  concurrent  systems  usually  define  a  basic  component,  an 
asyw  hronous  process  with  facilities  for  external  commit  t  (cations  and  synchronisation.  Ihe 
process  is  basic  in  the  sense  that  it  is  the  building  module  of  concurrent  systems.  The 
details  of  the  proposals  vary  a  great  deal,  and  we  shall  mention  some  which  have  an 
influence  on  the  way  processes  may  be  composed  together. 

One  difference  is  whether  communications  is  mainly  by  access  to  shared  memory,  or  by 
message  passing.  In  shared  memory  systems  (Simula^'’  [Dahl  70],  Monitors  |Hoare  74], 
Concurrent  Pascal  [lirinch  Hansen  77],  Modula  [Wit Hi  77]),  processes  communicate  by 
writing  and  reading  shared  variables.  Access  to  shared  objects  gives  a  tight  coupling  of 
processes  and  can  result  in  efficient  implementations.  Synchronisation  can  also  be 
achieved  by  setting  and  testing  shared  variables,  either  by  ordinary  assignment  or  through 
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spccial  signalling  facilities  of  the  language. 

The  early  proposals  which  eschewed  shared  memory  (PI  I  IS  (Feldman  79j, 
Communicating  Sapiential  I'rocesses (CSP)  [lloare  78].  Distributed  Processes  (DP)  |Hi inch 
I  lansen  78],  Actors  |l  lev.  ill  77])  promoted  message  passing  in  v  arious  forms  on  the  grounds 
of  simplicity,  reliability  and  clarity  of  expression,  at  least  with  respect  to  communications 
and  synchronisation.  It  is  interesting  to  note  that  some  of  the  most  recent  proposals 
(Synchronising  Resources  (SR)[ Andrews  81],  K-C'l.U  [I  iskov  and  Siheiller  81],  Modular 
Processes  (MP)  (Choi  8 1 1)  allow  shared  variables  (with  the  recommendation  that  they  he 
used  sparingly  and  with  care).  The  sharing  of  variables  ou  ms  within  an  explicit  grouping 
of  processes  (viz.  the  resource  in  SR,  guardians  in  I  -Cl  .U  and  the  node  in  MP). 

Communications  and  synchronisation  issues  are  often  difficult  to  separate  in  particular 
language  proposals,  for  it  is  frequently  the  case  that  both  aspects  are  involved  in  the  same 
language  feature:  hot  example,  the  input  and  output  commands  of  CSP  arc  the  sole  means 
of  communication  and  synchronisation.  These  issues  have  been  nealiv  separated  bv  (.'hoi 
(Cl  toi  81],  where  for  each  communication  event  there  is  a  process  which  provides  a  service, 
and  a  prmvss  which  is  requesting  a  service  (the  sender  of  the  message).  Synchronisation  is 
generally  the  concern  of  the  sender  of  the  message,  and  there  are  three  possible 
arrangements,  the  no-wait  send,  the  wait  send  and  the  remote  call.  With  no- wait  send,  the 
sending  process  does  not  synchronise  with  die  destination  process,  and  continues  execution 
after  sending  the  message  (e.g.  PU  PS).  With  wait  send,  the  sending  process  synchronises 
with  the  nrcipt  of  the  message  by  the  destination  process,  then  both  processes  continue 
independently  (e.g.  CSP).  With  remote  call,  the  sending  process  sytichumiscs  with  the 
co/u/t/cZ/o/t  of  the  service  requested  by  the  sender  and  invoked  by  the  receipt  of  the  message 
(e.g.  DP). 

From  the  point  of  view  of  the  receiver,  three  kinds  of  service  are  identified,  message 
service,  procedure  service  and  subprocess  service.  A  message  service  simply  receives  the 
message,  perhaps  assigning  values  to  local  variables  in  the  receiver,  and  the  receiving 
process  then  continues  normal  execution.  If  the  message  requires  a  reply,  it  must  he 
explicitly  constructed  and  sent  by  the  receiver  as  a  new  communication  (e.g.  CSP  and 
PI. I  I  S).  With  piocvdurc  service,  message  reception  invokes  a  procedure  to  handle  the 
message,  which  may  also  construct  the  value  of  a  reply  (the  "out"  variables  in  DP  and  Ada 
(Ichbiah  7b]).  Lastly,  a  service  may  be  provided  by  a  process  rather  than  a  procedure,  for 
greater  eoncuircncy.  In  MP,  subprocesses  are  created  dynamically  to  handle  subprocess 
service  requests,  while  in  SR,  all  requests  are  handled  by  processes,  but  the  processes  are 
not  dynamically  created.  Hie  arrangements  for  sending  and  receiving  described  above  are 
largely  orthogonal,  and  all  meaningful  combinations  have  been  proposed  in  the  literature. 

I  he  proposals  for  gioupinp  processes  advanced  in  this  paper  pci  mil  the  construction  of 
process  gii'iip-.  which  achieve  till  the  arrangements  for  sending  and  receiving  surveyed 
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above. 

Communications  is  mediated  by  arrangements  such  as  sender  re  ,'civer  pairing  (as  in  CSI*). 
ports  |Bai/er  71],  message  types  [Milne  and  Milner  ?l>]  u  invidious  |  Feldman  1{)]. 
conctructions  [Barter  7  S  ] .  pattern  matching  [Hewitt  >')\  and  vari  his  notations  such  as  I  kith 
hxpressions  [Campbell  and  I  laberman  7  I|.  and  Input  Idols  |\  an  ■  Jen  Bos  et  al  81]. 

Major  difference-sexist  in  the  structure  of  the  process  es  themsel  •  es.  largely  determined  by 
the  kinds  of  service  piovidecl.  In  CSI*.  the  basic  process  is  mply  a  list  of  sapiential 
commands,  using  a  nondeterministic  guarded  command  notatio  a  to  control  input,  output 
and  ordinary  sequential  execution.  Ihe  communications  comma  ids  appear  as  in-line  code. 
In  contrast,  DP  provides  a  pioccss  with  service  procedures  whit  a  may  be  called  remotely, 
using  a  monitor-like  discipline.  A  process  may  have  a  convenln  mal  process  body  as  well, 
and  the  execution  of  the  mam  body  and  the  service  procedure: .  interleave  in  an  unusual 
way  [Welsh  et  al  80].  Ada  has  both  in-line  message  receivers  (cm  l  ies)  and  communications 
procedures,  in  an  attempt  to  combine  the  advantages  of  CSP  a  U  DP.  The  proposals  for 
grouping  processes  in  this  paper  are  independent  of  proees  ;  structure:  the  example 
program  at  the  end  of  the  paper  uses  in-line  code  for  services,  hi  it  it  is  easy  to  sec  how  the 
other  kinds  of  service  may  be  used. 


2.2  The  Composition  of  Systems  of  Processes 

A  simple  way  to  compose  processes  is  to  form  a  loose  group  ng  of  processes  within  a 
common  communications  environment,  with  a  global  conventu  >n  for  process  names  and 
messages.  Various  refinements  of  this  model  have  been  propos  :d  which  provide  ways  of 
restricting  the  scope  of  these  names.  For  example,  Milne  and  ivliiner  use  an  operator  to 
restrict  the  visibility  of  port  names  [Milne  and  Milner  1%  O  IP  uses  textual  nesting  of 
processes  (parallel  commands)  and  Algol-like  scope  i  tiles  for  acta,  ss  to  variables  in  different 
processes.  Ihus  there  are  shared  variables,  but  a  "dis  iointness"  ]  roperty  ensures  that  there 
is  no  shared  write  access. 

Textual  nesting  has  also  been  used  to  construct  hierarchical  gi  ou  ps  of  processes  w  ith  scope 
rules  on  process  names  to  hide  the  process  structure  of  groups;  bom  the  point  of  view  of 
the  sendet  of  a  message,  the  destination  is  simply  a  process.  The  destination  may  in  fact  be 
a  group  of  processes,  and  the  primitive  process  within  the  j-roup  which  receives  the 
message  is  determined  by  the  group  composition  and  the  type  ■  f  the  message  [Barter  78]. 
Structure  hiding  has  been  achieved  in  CSI*  by  the  uso  of  a  "hole  -in-scope"  rule  whereby  a 
process  name  is  known  in  all  of  the  enclosing  procesu-s  but  not  ir  i  the  named  process  itself; 
structure  hiding  is  used  in  a  stepwise  refinement  programming  methodology,  where  each 
refinement  step  adds  an  additional  process  to  a  p.'oup  in  oi  let  to  modify  the  group 
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bchaviour  [lloare  and  McKcag  79],  Shapiro  has  developed  lhis  methodology  through  an 
extension  of  CSP  which  adds  soir.e  flexibility  lo  the  naming  conventions  lor  processes  and 
message  consimetors.  and  applied  it  to  a  large  system  design  (Shapiro  8()J. 

Some  recent  proposals  (SR.  IT.'I.U,  Ml’),  influenced  by  the  additional  considerations  of 
distributed  systems,  have  defined  a  middle-level  structure  involving  a  group  of  processes, 
and  some  shared  objects  (usually  variables).  Ibis  grouping  may  he  regarded  as  the 
counterpart  of  a  processor  node  in  a  network  of  processors.  The  authors  of  SR  and  MP 
regard  these  special  groups  as  being  different  to  processes,  and  do  not  allow  arbitrary 
nesting  of  processes  and  groups. 

The  most  interesting  composition  ideas  have  come  from  languages  which  were  not 
primarily  intended  for  concurrent  programming,  but  had  a  strong  object-oriented  approach 
and  witli  particular  applications  in  mind  (Sintula67,  Smalltalk  [Kay  and  Goldberg  77, 
Ingalls  78],  Thinglab  [horning  81]  and  l.isp  Machine  Flavors  [Cannon  79,  Weinreb  and 
Moon  SI]).  The  reason  is  that  without  the  complication  of  concurrency  it  is  natural  to 
exploit  the  advantages  of  shared  memory,  and  this  has  been  done  in  most  imaginative  ways. 
In  these  languages  we  see  the  composition  of  processes  to  mean  the  actual  merging  of  state 
spaces,  process  bodies  and  service  procedures,  involving  a  much  tighter  composition  than 
the  loose  coupling  described  cailicr.  Sinuila67  introduced  the  idea  of  class  concatenation, 
where  a  class  could  inherit  the  attributes  of  another  class,  by  this  method,  superclass 
hierarchies  amid  be  constructed.  The  original  intention  was  to  provide  language  support 
for  program  modularity,  where  the  modules  (classes)  would  correspond  closely  with  the 
conceptual  layers  of  a  system  design.  Class  concatenation  also  foreshadowed  another 
important  kind  of  group  composition  where  one  object  encapsulates  another  (sec  later). 
The  idea  of  class  introduced  by  Siinulu67  lias  been  extraordinarily  influential,  even  though 
some  of  its  details  have  been  criticized  (the  details  or  concatenation.  Algol  scoping  and 
remote  accessing  of  class  attributes). 


2.3  Superclass  Schemes  and  Process  Composition 

Languages  such  as  Siimda67  and  Smalltalk  allowed  class  objeccLs  to  inherit  attributes 
(procedures,  methods  and  even  vaiiables)  from  other  classes  by  class  concatenation. 
However,  the  structures  which  can  be  built  this  way  are  strictly  hierachical,  and  may  be 
classified  as  single  supeiclass  systems.  Multipie  superclass  systems  such  as  Thinglab  and 
Klavois  allow  inheritance  lattices.  ITie  inheritance  mainly  applies  to  the  inheritance  of 
methods  (which  may  be  viewed  as  message  services),  although  there  may  be  some  state 
space  sharing  as  well. 


In  the  flavor  system,  a  flavor  (a  class* like  specification)  can  he  constructed  from  other 
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llavors  by  a  technique  called  ’'mixing".  A  mixed  flavor  mac  haw  comp;  mk  ms  such  that 
more  than  one  component  has  a  method  with  the  same  name;  an  important  c  mtiibuiion  of 
the  l-hivor  system  is  that  if  an  object  of  the  mixed  flavor  is  instantiated,  and  a  method  of 
that  object  is  invoked,  more  than  one  method  may  he  curuteJ  from  the  set  of  component 
methods.  I  he  programmer  selects  a  one  of  a  set  of  method  nunhinaf  ions  to  conitol  which 
component  methods  are  executed,  and  in  which  ordet.  The  delimit  method  combination  is 
called  daemon  combination  which  allows  methods  to  be  classified  as  before,  .primary  ui  after 
methods;  all  before  methods  are  handled  first,  then  the  single:  primary  method,  and  finally 
the  after  methods  are  handled.  Within  the  before  and  alter  groups  of  methods,  method 
order  is  determined  by  the  order  in  which  component  flavors  are  mixed  to  form  the 
composite  flavor  (in  fact  a  tree  walk  order).  In  every  case,  the  message  handling  policy  is 
statically  determined  by  the  text  of  the  flavors  and  methods.  Our  proposal  differs  in  several 
ways.  Firstly,  the  specification  of  group  policy  is  separated  from  that  of  group 
composition;  secondly,  policy  is  expressed  only  at  the  group  level,  and  not  within  methods, 
and  finally,  dynamic  policies  will  be  allowed  (dynamic  in  the  sense  that  method  ordering 
can  change  depending  on  the  execution  environment). 


X  Communications  Policy 

In  this  section  we  address  a  question  which  is  fundamental  to  any  proposal  for  forming 
processes  into  groups,  namely  how  is  a  message  received  within  a  group  when  it  is  sent  lo 
the  group  as  a  whole?  This  question  may  be  simplified  by  using  message  types  and  ensuring 
that  there  is  always  exactly  one  process  in  the  group  able  to  receive  messages  of  that  type. 
We  define  group  policy  to  be  a  specification  of  how  messages  of  a  given  type  will  be 
received  within  the  group,  and  this  will  be  the  key  concept  upon  which  other  ideas 
concerning  transaction  handling  and  encapsulation  will  be  based.  We  shall  now  examine 
more  flexible  policies  such  as  broadcasting  to  all  processes  able  to  receive  the  message,  or 
the  selection  of  some  subset  of  those  eligble.  Of  course  policy  may  he  implemented  in  an 
additional  "policy  manager"  process  (dispatcher)  associated  with  the  group,  but  we  shall 
describe  policies  in  a  descriptive  notation  through  policy  expressions,  examples  of  which 
now  follow. 

Consider  a  group  of  processes  P,  and  a  message  type  "msg".  I.et  (PI,  P2,  ...  Pn)  be  those 
processes  of  P  which  accept  messages  of  type  msg.  Three  basic  policies  are  now  given  by 
example. 


o 


A  policy  of  selection  for  P  is  written;  policy  msg:(Pll]  P?) 
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Only  processes  I’l  and  1*2  are  considered  as  possible  destinations  for  messages  uflypc 
msg.  The  choice  between  IM  and  P2  is  nondeierminisiic,  all  oiltei  things  being  equal. 
(An  implementation  could  choose  the  first  process  ready  to  receive.)  l:or  example, 
consider  a  print  request  sent  to  a  pool  of  print  resources,  and  the  request  may  be 
satisfied  by  any  member  of  a  subset  of  printing  resources  (e.g.  those  three  which  are 
nearby).  The  policy  for  the  group  "printer-poor  may  be  expressed: 

policy  print- request:  (print-resoiuee(l)  []  prim-resouri:e(2)  |]  priiu  resoiirce(3) ) 

o  A  policy  of  broadcasting  for  P  is  written:  policy  msg:(Pl  II  P2) 

Both  PI  and  P2  receive  the  message,  but  the  order  is  unspecified.  For  example,  a 
request  for  some  services  may  also  be  logged  on  an  accounting  file,  and  registered 
with  a  load  monitor.  The  policy  for  such  an  encapsulated  printer  pool  may  be 
expressed: 

policy  print- request:  (  printer-pool  //  accounts  //  load-monitor ) 

o  A  policy  of  serial  broadcasting  for  P  is  written:  policy  msg:(Pl  ;  P2) 

Both  PI  and  P2  receive  the  message,  but  process  PI  must  complete  the  processing  of 
the  message  before  P2  starts.  Serial  broadcasting  is  likely  lobe  most  useful  in  groups 
with  shared  memory;  for  example,  it  is  the  default  policy  for  calling  combined 
methods  in  the  Lisp  Machine  Flavor  system.  Both  forms  of  broadcasting  require  a 
convention  when  used  with  remote  call,  to  determine  which  service  sends  the  reply; 
see  later  for  default  policies. 

An  important  degenerate  case  is  policy  msg:(Pl),  which  simply  directs  all  messages  of  type 
msg  to  PI. 

A  policy  expression  describes  the  disposition  of  every  message  received  by  the  group,  and 
therefore  may  he  regarded  as  a  repeating  construct.  (Additional  notation  will  be 
introduced  later  to  specify  repetition  of  inner  components).  A  policy  expression  for  a 
group  cannot  dirculy  affect  the  1  ccpliun  ol  messages  ny  that  group;  policy  only 
determines  the  disposition  of  a  i  essage  win...  a  is  received  by  the  group. 

Compound  policy  expressions  may  be  formed  in  three  obvious  ways: 
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o  By  nesting  "roups  as  in: 

policy  for  group  P  is  policy  nv.g:(Pl  []  P2) 
policy  lor  group  Q  is  polio)  in  ,g:(()l  [)  Q2) 
policy  lor  group  PQ  is  policy  msg:(P  //  Q) 

w  here  a  message  for  group  PQ  is  sail  lo  PI  or  P2  and  also  lo  Q1  or  Q2. 

o  By  expression  nesting,  e.g.  policy  lor  P  is  policy  tmg:((Pl  {]  P2)  //  (I’d  []  P4)) 

where  a  message  for  group  P  is  sent  to  PI  or  P2  and  also  to  P3  or  P4. 

o  As  a  sequence  of  policies,  policy  msg:((Pl  {]  P2)  » (P3  Q  P4)) 

The  initial  policy  is  (PI  U  P2).  which  directs  one  message  to  either  i’l  or  P2.  Idle 
policy  then  changes  to  (PA  [|  P4),  and  after  that  tile  policy  expression  repeats.  A 
sequence  of  policies  achieves  a  similar  effect  to  actor  replacement  [I  lew  ill  el  al  79], 


In  a  language  using  policy  expressions,  some  convention  for  default  policy  would  he  useful, 
and  perhaps  some  way  of  defining  message  ty  pe  aliases  (a  reasonable  dc  fault  would  be  the 
selection  of  a  single  receiver,  using  a  static  criterion  such  as  text  order  in  the  group 
description,  or  a  dynamic  selection  over  all  eligible  processes). 


.4.2  Policy  Model 

The  semantics  of  policies  are  now  given  as  code  for  a  virtual  group  message  handler.  The 
notation  is  CSP-like,  where  "Plmsg"  is  the  usual  (ASP  wait  send  of  message  "msg"  to 
destination  P.  The  notation  is  extended  so  that  "P.msg"  signifies  a  remote  call  to  P:  if  a 
process  Q  executes  a  remote  call  "P.msg"  which  activates  the  guarded  command  "?msg  --> 
command-list",  then  "P.msg"  in  Q  does  not  terminate  until  "command-list"  in  P  does. 
Also,  the  input  command  "?nisg"  differs  from  CSP  in  that  it  does  not  name  a  sender,  but 
w  ill  receive  messages  of  the  appropriate  type  {Barter  7Sj.  I'he  three  basic  policies  arc: 

policy  msg:(Pl  |]  P2)  ~>  { ?msg  -->  [  true  -->  PI. msg  |]  true  ~>  P2.msg  ]] 

policy  insg:(Pl  //  P2)  ~>  |  ?msg  ->  [f  PI. msg  ]  //  [  P2.msg  )]] 

policy  msg:(Pl  ;  P2)  ->  [  ?msg  -->  [  PI. msg  :  P2.msg  1] 


' 


I 
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Note  that  all  the  virtual  handlers  have  the  same  structure,  [  I  I  IS  -->  K I  IS  ],  where  I  I  IS  is 
always  the  vit  tual  input  command  lor  the  group,  and  Rl  IS  is  a  simple  transformation  of  the 
policy  expression.  Virtual  handlers  lor  nested  policy  expressions  are  similarly  constructed 
by  repeated  transformation: 

policy  msg:((Pl  [j  P2)  II  (P3  []  P4»  => 

[  ?msg  -->  [  [  true  -->  Pl.msg  []  true  -->  P2.msg  ] 

//  ( tine  -->  Pl.msg  |]  true  *->  P2.msg  ]]] 

See) lienees  of  policies  result  in  sequential  composition  of  virtual  handlers;  the  operator 
"»"  takes  precedence  over  the  others  in  deriving  the  virf  handler; 

policy  msg:(Pl  »  P2)  ~>  [  ?msg  -->  Pl.msg  ]  ;  [  ?tnsg  •  *2.msg  ] 

policy  msg:((IM  []  P2) »  (P3  Q  P4))  => 

If  ?msg  -->  |  true  -->  Pl.msg  f]  true  -->  P2.msg  ]] ; 
l  ,’nisg  -->  [  true  -->  Pl.msg  []  true  -->  P2.msg  |]] 


4.  Communications  Protocol 

Hie  meaning  of  a  process  may  be  given  in  terms  of  its  input-output  behaviour  [Milne  and 
Milner  7‘>J.  Behaviour  can  also  be  expressed  as  the  set  of  all  possible  communication 
sequences  [Moure  7.XJ.  In  the  Actor  model  of  concurrency,  an  actor  receiving  a  message 
may  change  its  local  state,  send  messages  to  other  actors  and  create  new  actors.  The  arrival 
of  a  message  at  an  actor  is  called  an  event,  and  local  time  for  an  actor  is  the  arrival  ordering 
or  events.  Message  sending  is  not  important  in  the  event  ordering  as  the  model  is 
asy  nchronous  .  However,  an  event  can  cause  a  message  to  be  sent,  and  hence  cause  another 
arrival  event;  in  which  case  the  first  event  is  said  to  activate  the  second  event. 
Communications  between  actors  is  represented  by  such  activation  orderings.  1'he  meaning 
of  a  program  is  given  by  the  combined  ordering  [I  lew  itt  et  al  79,  Ginger  81]. 

In  ibis  paper  we  are  interested  in  control  over  input  messages,  and  input  protocol  will  mean 
lust  the  input  behaviour  of  a  process.  We  shall  refer  to  input  protocol  as  protocol  for  short 
(this  is  a  narrower  definition  than  used  in  the  literature  on  networks). 


live  protocol  of  a  process  is  determined  by  the  mechanisms  within  the  process  for  selec  ting 
the  next  message  to  receive  from  a  set  of  pending  messages.  Iliese  mechanisms  depend 


(  ..I.  Barter 


-9  - 


is  pi  mi  an  ahilil\  U'  disc i  im  in  itc  ivlv.  o<  n  mcv-.ig'.w  b  m  mu.'  i’l.  .Im!  me  .  ie  I:  a>  u  i  o. si 
ordering  |l  low  ill  ct  al  7‘)|.  er  on  th- •  basis  ul  iiKssip-’C  allnhutcs  ,-ucii  as  l\pc.  --.i,,  ■.  i  .aid 
pnority.  Arrival  ordciinp  is  somclimcs  used  in  combination  with  message  aiinbau.s  ,<■>  a 
subsidiary  selection  cniciu'n  (1*1.1  i ‘S.  <  OSLOI.  |Kopei  and  Harter  H|).  I  -t i  Is-k 
mechanisms  have  been  used; 

o  Firstly .  there  are  pi,  esses  which  have  a  process  bud\  which  controls  the  selo. lion  of 

the  next  message  to  he  received,  using  in-line  rei eive  commands  idle  input  a  iiimand 
of  (SI*  and  the  entry  of'  Adi).  I  oca  I  variables  on  he  used  to  cotitro*  message 
selection  by  normal  How  ot  control  and  In  guanhng  input  commands. 

o  Secondly.  there  are  seheme.s  which  have  service  procedures  or  processes  which  arc 
directly  accessible  to  other  prc>eesscs.  without  the  control  of  a  "main  body"  u.g.  SR, 
K-CI.U).  Local  variables  can  he  used  to  guard  access  to  services. 

o  Thirdly,  message  reception  can  be  entirely  determined  by  arrival  ordering'  m  Actor 
languages,  messages  can  he  typed  (implicitly  In  pattern),  and  the  pattern  may  he 
matched  against  a  sot  of  alternative  actions,  hut  the  patient  matching  dcieimiacs  the 
body  which  is  to  he  executed,  not  the  message  to  he  selected.  While  languages  such 
as  CSP  have  "choice  nondeterminism"  which  alTects  message  selection  ordering, 
Actor  languages  only  have  "at rival  nondeterminism"  due  to  asynchronous 
communication  [(.linger  S1J. 

ci  Linally.  there  are  languages  which  use  a  separate  notation  to  control  message 
selection,  such  as  Path  bxprcssioiis  [Campbell  and  I  label  matt  74]  and  inpie  Tools 
[van  den  Bos  et  al  81], 


Lath  expressions  are  based  on  regular  expressions,  using  the  names  of  the  service 
procedures  of  a  resource.  As  well  as  scheduling  service  lequests.  Lath  expressions  also 
control  the  amount  of  concurrency  in  the  resource  services. 

I  lie  Input  Tool  Process  model  provides  an  event-driven  model  based  on  input  events, 
controlled  by  input  rules.  An  Input  Tool  hac  a  name,  an  input  rule,  a  tool  body  and  an 
initialisation  section.  Tools  may  be  composed  in  parallel,  or  nested.  An  input  rule  is  based 
on  a  regular  expression  notation,  using  the  names  of  other  tools.  If  an  input  rule  is 
matched,  the  tool  body  is  executed,  and  that  tool  name  may  cause  further  matching  in  an  in 
input  rule  at  a  higher  level.  Direct  communications  between  processes  involves  a  match 
between  a  send  command  in  one  process  and  a  receive  rule  in  another  (a  tool  may  specify  a 
receive  rule  instead  of  an  input  rule).  A  parser  uses  the  input  rules  to  dynamically  construct 
the  currently  "active"  structure  (if  input  tools  (a  tree  for  each  proces,  whose  terminal  nodes 
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arc  Basic  tools  with  receive  rules).  Inputs  which  do  not  match  the  ctmcni  stiucture  are 
ignored.  I  h  ns  in  put  rules  control  input  protocol  and.  as  we  shall  show,  some  aspects  of 
wh.n  we  have  called  policy. 

Input  rules  can  be  used  to  control  both  policy  and  protocol  (indeed  the  aiiih<>is  do  not  draw 
the  distinction).  Because  the  Input  Tool  model  has  strong  similarities  with  our  police 
proposals  and  strong  differences  with  our  treatment  of  input  protocol,  we  shall  discuss  the 
model  in  some  detail: 


4.2  The  input  Tool  Model 

Hie  example  of  a  printer  server  is  given  [van  den  Bos  ct  al  81]: 

tool  printer  --  input  (lust-lino;  |more|:  source  -->  lind>)$  end 
bool  more:  process  set  source; 
tool  rust-line  -  input  line  end 
if  more 

then  source  :  -  [sender} 
fi 

end 

tool  line  -  receive  string  msg; 
more  :  =  (msg  <>  HOT); 
if  more 

then  lineprint(msg) 
else  skip-page 
fi 

end 

end 

Ihe  input  rule  uses  (or  sequences  of  matches,  for  repetition,  and 

|<boolean-expression>|:  for  guarding.  The  notation  "source  ->"  restricts  input  messages  to 
be  from  a  partial  lai  sender,  in  this  example  it  is  the  one  bound  by  the  assignment  "source 
--  [sender}". 

When  the  tool  "printer"  is  activated,  the  parser  activates  the  tool  "first-line",  and  through 
it,  die  tool  "line";  "line”  is  a  basic  tool  which  receives  a  message  "msg",  which  matches  its 
receive  rule,  and  so  the  body  of  "line"  is  executed.  Ibis  matches  the  input  rule  of 
"fust-line",  and  so  its  body  is  executed,  and  the  component  "first-line"  of  (he  top-level  is 
matched.  The  parser  now  moves  to  the  next  component  of  the  top-level  input  rule:  this 
will  be  "|morcJ:  source  ->  line!}"  if  the  boolean  guard  "more"  is  true,  but  if  "more"  is  false 
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th;il  component  will  he  i n \ isi hie  to  the  parser.  and  v>  the  next  component  will  again  be 
"rust-line". 


A  second  example  shows  input  rules  used  to  direct  a  message  of  the  same  t\pe  to 
alternative  tools: 

tool  squash  -  input  |go-on|:  (star  -t  nostar)$  end 
tool  star  -  input  charncter(c):  |e  "*"|  end 
end 

tool  nostar  =  input  chanieter(c):  |c  <>  "*"|  end 

if  c  -  FOI-  then  go-on  :  -  false  fi 
end 

init ... :  go-on  :  =  true  end 
end 

1'hc  operator  "4  "  specifies  a  choice  between  two  tools,  and  the  inpul  rule  Vliarnoter(c):  |e 
----  uses  a  post-test  on  the  value  of  the  parameter  "c",  so  that  the  post-test  must 
succeed  if  the  rule  is  to  match. 

An  example  of  a  bounded  buffer  is  given  to  illustrate  an  input  rule  controlling  a  simple 
input  protocol;  the  example  is  given  here  in  abbreviated  form: 

tool  buffer  -  input  (|eount  <sizc|:  put  i-  |coum>0|:  get )$  end 

tool  put  -  receive  char  c; 

end 

tool  get  =  receive; 

end 

end 


Hie  parser  does  not  activate  the  tool  "put"  if  the  buffer  is  full,  and  similarly  does  not 
activate  the  tool  "get"  if  the  buffer  is  empty.  The  boolean  guards  are  computed  within  the 
bodies  of  put  and  get. 
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t  he  example  programs  show  three  use  s  of  input  rules.  Hie  Hi  si  example  slums  an  input 
rule  specifying  a  message  polios:  an  inf  tit  line  is  processed  by  either  one  oi  both  toois.  I  he 
purpose  is  to  pmviile  some  en  eapstihiti  m  of  tool  "line"  by  tool  "first-line".  This  particular 
ene;  psulation  does  not  generalise  well:  encapsulation  will  he  treated  later .  I  he  third 
example  also  specifies  policy  lor  input  characters,  using  the  tool  "star"  or  "nostar" 
depending  on  the  data.  In  both  examples,  the  input  rules  affect  policy  but  not  input 
protocol.  In  the  second  example,  the  input  rule  controls  protocol  in  the  sense  that  it 
directly  determines  the  scheduling  of  input  icquests.  In  all  three  examples  the  input  inks 
exercise  control  through  shared  variables. 

I  he  use  of  program  variables  in  these  e  xpressions  allows  arbitrary  interactions  between  the 
expicssions  and  the  c  ode  of  the  processes  controlled.  But  typical  proloco1  and  scheduling 
deset iptions  do  involve  variables  which,  are  local  to  (and  sometimes  shared  between)  the 
processes  concerned;  this  is  a  strong  icason  not  to  place  these  descriptions  in  a  separate 
cxpiession,  but  to  leave  them  in  the  code  ofilie  processes  them  solves.  On  the  other  hand, 
we  shall  show  that  policies  have  less  to  do  with  individual  processes  and  their  variables,  and 
more  to  do  with  groups  of  processes  and  message  sequences;  for  this  reason  wc  shall  argue 
that  groun  policy  is  belter  placed  in  a  separate  description  associated  with  the  group,  and 
that  a  separate  notation  is  useful  for  its  description. 

Because  the  method  of  process  composition  suggested  in  this  paper  does  not  involve 
message  re-scheduling,  the  protocol  of  a  group  is  simply  the  merge  of  individual  protocols 
(i.e.  all  orderings  which  preserve  the  partial  ordering  of  the  component  processes).  Next 
wc  show  how  policy  and  protocol  may  interact  without  using  shared  variables  in  either  the 
processes  or  the  policy  expressions. 


5.  Policy-Protocol  Interaction 

Consider  a  group  of  children  and  gifts  arriving. 

'IT.e  group  is;  (Sharon,  Carol,  Jenny,  Michael) 
The  messages  are;  (gill,  boy-gift,  girl-gift) 


Some  example  policies  are: 

policy  gift:(Sharon  »  Carol  »  Jenny  »  Michael)  --  i.e.  take  turns, 
policy  girl-i’ilt:(Sharon  [j  Cared  Q  Jenny)  --  i.e.  choice 
policy  boy  -gift :(Micl tael)  --  i.e.  single  receiver 

The  three  polities  are  independent  -  e.p.  the  policy  for  messages  of  type  "gift"  has  no 
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influenceon  the  policy  lor  messages  of  the  type  “girl-gift". 

Consider  the  follow  mg  policies: 

policy  gift:  (Sharon  //  Carol  //  Jenny  //  Michael) 
policy  gift:(Sharon  ;  Carol  :  Jenny  :  Michael) 

In  these  two  policies,  for  every  incoming  message  of  type  "gift",  four  messages  are  copied 
to  the  group  members,  concurrently  in  the  former  policy  and  sequentially  in  the  latter. 

The  policy  for  "giri-gift"  is  not  fully  determined  by  the  policy  expression;  an 
implementation  may  have  some  additional  criteria  for  making  the  choice,  such  as  choosing 
the  process  which  has  been  waiting  longest  lot  a  message  of  that  type.  (An  alternative 
strategy  is  to  choose  without  consideration  of  w  Mother  processes  are  ready  or  not,  and  wait 
if  the  chosen  process  is  not  ready;  this  can  lead  to  more  deadlocks  than  the  Hist  strategy). 
Rather  than  regarding  the  previous  as  an  implementation  issue,  the  selection  method  could 
be  part  of  the  language  definition  and  exploited  to  schedule  message  reception  or 
synchronisation;  but  this  encourages  a  dangerous  interdependence  between  processes  in  a 
way  which  undermines  modularity  and  clean  interfacing.  We  now  examine  some 
policy -protocol  interactions  which  depend  only  on  more  general  aspects  of 
communications: 

o  A  process  may  terminate,  which  is  a  most  drastic  change  of  protocol.  The  most 
desirable  behaviour  with  respect  to  group  policy  if  a  component  of  the  group 
terminates  will  depend  on  the  composition  method.  If  the  terminated  component  is 
composed  with  the  policy  operators  "//"  or  "|J",  then  the  process  may  be  dropped 
(dynamically)  from  the  policy  provided  that  there  is  some  live  component  to  receive 
the  message:  if  not,  the  group  should  abort. 

o  A  process  may  close  a  typed  message  service,  which  is  similar  to  termination,  but  only 
with  respect  to  that  message  type  and  the  a  ^responding  message  policy. 

o  The  policy  for  a  group  is  by  definition  a  repealing  construct,  and  as  such  associates 
with  message  sequences  rather  than  a  single  message,  lire  policies  given  earlier  could 
have  made  this  explicit  with  a  repetition  operator  such  as  the  Kleene  star,  c.g.:  policy 
nisg:(Pl  |]  P2)*. 

An  explicit  operator  is  necessary  to  express  repetitions  of  policies  within  sequences  of 
policies,  c.g.: 
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poliey  msg:((IM  [)  l>2)*  » (lJ3  (]  P4)*) 

In  this  policy,  a  sequence  of  messages  is  dispatched  under  the  policy  (IM  (]  P2)*, 
before  the  policy  changes  to  (P3  Q  IM)*.  Some  means  of  breaking  the  sequence  is 
required,  and  we  propose  an  explicit  break-policy  signal  rather  than  a  test  on  a 
program  variable.  A  logically  associated  sequence  of  messages  is  usually  called  a 
transaction.  It  is  useful  to  strengthen  the  attributes  of  a  transaction  by 
sender-receiver  bindings,  and  two  operations  are  proposed  for  this  purpose: 
atlacli-sciidcr  and  break -sender. 

break-policy  has  the  following  effect:  If  the  current  policy  is  part  of  a  sccpience  of 
policies,  and  not  the  last  policy  in  that  sequence,  the  next  policy  becomes  the  current 
policy:  otherwise  the  break  is  passed  up  to  the  next  level,  if  any.  When  there  is  no 
"next  level  up"  (the  group  is  not  a  component  of  another  group),  the  policy  at  that 
level  does  not  signal  a  break,  but  restarts  the  entire  policy  expression  at  that  level. 
(Repetition  in  policy  expressions  and  the  break-policy  operation  are  similar  to  catch 
and  throw  in  some  versions  of  l.isp  [Weinreb  and  Moon  81].) 

atiach-scnder  restricts  all  further  messages  received  by  the  group  to  be  from  the 
sender  of  the  last  message,  and  this  prevails  until  break-sender  is  executed  within  a 
process  of  the  same  group. 


The  three  policy  operations  described  above  will  be  illustrated  in  an  example  after  a 
discussion  of  encapsulation. 


6.  Kucapsulation 

Simu!a67  supports  a  form  of  encapsulation  through  class  concatenation;  a  special  symbol 
inner  is  used  to  mark  a  point  in  the  code  of  the  body  of  a  process,  to  identify  where  Uie 
code  body  of  the  encapsulated  may  be  regarded  to  notionally  execute.  A  similar 
encapsulation  facility  with  respect  to  method  bodies  is  available  in  the  Flavor  system 
(wrappers). 

Hewitt's  serialisers/guardians  may  be  used  to  encapsulate  a  resource  process  by 
intercepting  and  re-scheduling  all  communications  with  the  resource.  I  he  guardian  acts  on 
behalf  of  the  user  of  the  resource.  The  purpose  of  the  encapsulation  is  to  enforce  a  stronger 
ptolocol  than  that  of  the  resource  itsdf;  i.e.  the  resource  may  have  been  designed  without 
considering  the  possibility  of  careless  or  malicious  use,  and  the  encapsulation  is  then 
designed  to  o  mtpensate  for  this. 


(...I.  Hurler 


-  15  - 


Although  shared  variables  arc  often  exploited  to  provide  the  kinds  of  run  lime 
environment  encapsulation  possible  in  the  languages  described  above,  we  shall  only  discuss 
sharing  through  the  communication  environment,  rather  than  through  process  state  spaces. 
The  most  important  communication  attributes  to  be  slutted  are  those  to  do  with 
transactions  involving  more  than  one  message  passing  event.  Examples  of  transaction 
attributes  of  interest  such  as  policy-sequence  bindings  and  sender-receiver  bindings  have 
already  been  mentioned. 

We  now  introduce  the  construct  inner  to  provide  some  encapsulation  abilities  in  groups. 
The  name  inner  is  borrowed  from  Simula(>7,  but  because  it  is  used  without  access  to  shared 
variables,  its  semantics  is  different  to  that  in  Simula.  A  process  receiving  a  message  will 
execute  its  command  list  (or  service)  up  to  the  occurrence  of  the  inner  marker,  and  skip  the 
remainder;  when  an  entire  policy  expression  is  complete,  all  command  lists  whose 
remainder  parts  were  skipped  are  then  executed,  in  reverse  order  to  the  order  in  which  they 
were  skipped.  Kaeh  remainder  will  be  executed  as  many  times  as  it  was  skipped  in  each 
component  of  the  policy  expression. 

Thus  an  encapsulating  process  encapsulates  the  transactions  or  message  sequences  of  the 
encapsulated  process,  rather  than  its  execution  environment;  but  this  is  often  what  is 
required  anyway.  A  common  use  of  encapsulation  is  resource  locking,  where  only  requests 
of  the  current  transaction  are  allowed  to  access  the  resource,  and  all  other  requests  are 
locked  out  for  the  duration  of  the  transaction.  To  achieve  tiiis  effeci.  encapsulating  process 
could  contain  the  following  code; 

...  lock;  inner;  unlock; ... 

lit  the  following  example,  inner  is  used  to  illustrate  head  and  tail  encapsulation  in  the 
printer  problem.  The  example  is  an  extended  version  of  the  earlier  printer  example,  with 
the  added  requirements  that  each  file  be  printed  with  a  header  and  a  trailer,  both 
containing  information  extracted  from  the  first  line  of  the  file,  and  that  empty  files  should 
not  cause  a  page-skip.  The  programming  language  used  is  the  same  as  that  used  for  the 
description  of  virtual  group  policy  handlers  {Harter  7<S’|  for  the  sake  of  example,  and  it  is  not 
intended  that  the  group  policy  model  associate  with  any  specific  language. 

[  Printer ;: 

group-members  :  (New file,  Printline's, ...) 

policy  line  :  (Newlile*  »  Printlines*) 

..  policies  for  other  message  types 


(  '.J.  Mailer 


-16- 


1 

// 

[  Newfilc :: 

*i  ?line  --> 

1  line.eof->  skip 
(Jitol  line.eof  --> 
altacli-sender; 
print-  hcadcr(line); 
break-policy 
inner; 

print-trailer(1ine); 

page-skip; 

break-sender; 

I  ]  ] 

// 

[  Printlincs 
*1  ?linc  --> 

l  line.eof -->  break-policy 
Qnol  line.eof  ->  prini(line) 

)  ]  1 

The  modularity  achieved  is  typically  that  which  is  to  be  expected  from  careful 
encapsulation.  The  process  Newfile  only  performs  operations  at  the  file  level,  either  empty 
ones  which  arc  skipped,  or  non-empty  ones  which  have  headers,  bodies  (for  which  inner  is 
a  surrogate),  and  trailers.  The  process  Printlines  just  handles  sequences  of  lines  under  some 
prevailing  policy,  breaking  at  end-of-file. 

Note  that  the  sender-receiver  binding  is  now  handled  in  the  same  process,  and  that  the 
header  and  trailer  procedures  use  the  same  value  of  line  as  their  parameters. 


Conclusions 

Message  policy  has  been  defined  to  be  the  description  of  the  disposition  of  messages  of  the 
same  type,  when  received  by  a  group  of  processes.  Group  policy  applies  to  all  the 
processes  or  a  group,  but  for  a  single  message  type.  It  is  proposed  that  group  poliev  be 
specified  in  an  expression  which  is  separate  from  the  code  of  the  processes  of  the  group, 
and  in  a  separate  notation.  Separate  specification  seems  natural,  for  policies  arc  associated 
with  transactions  and  message  sequences  rathei  than  the  details  of  processes;  for  this  reason 
it  is  possible  to  write  policy  expression  which  arc  independent  of  process  state  variables. 
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and  as  well  use  a  simpler  control  notation  based  on  regular  expressions. 

Input  protocol,  on  the  other  hand,  applies  to  single  processes  (or  a  group  as  a  whole)  for  all 
message  types.  When  policy  aspects  are  separated  from  input  protocol,  scheduling  is  what 
usually  remains,  and  scheduling  often  has  strong  associations  with  process  state  x.niables; 
for  this  reason  it  is  often  difficult  to  specify  protocol  expressions  without  using  control 
constructs  which  access  process  state  variables.  Accordingly,  we  leave  contio]  oxer 
protocol  in  the  code  of  the  processes  themselves. 

Encapsulation  of  processes  is  presented  with  an  unusual  emphasis  on  the  transactions  and 
resources  which  associate  with  an  encapsulated  process  ratliei  than  the  state  space  of  the 
process  environment.  This  is  due  u>  the  notion  of  encapsulation  without  shared  variables, 
and  to  the  association  h  ween  group  policies,  message  sequences  and  transactions. 

We  have  tried  to  avoid  committment  to  any  particular  language  within  the  general 
message- passing  group  surveyed,  though  there  are  important  mtci actions  which  will  affect 
group  composition  and  policy  expression,  as  well  as  implementation  (e.g.  the  prescence  of 
remote  call  in  a  language  will  significantly  influence  implementation  strategies).  We  have 
not  argued  against  shared  variables  (in  small  amount),  but  have  shown  what  is  possible 
without  them.  I  lie  example  program  given  used  a  CSIMike  syntax,  and  suggested  a 
load-and-go  execution  environment.  We  believe  that  the  ideas  transfer  to  incremental 
execution  environments  as  well,  such  as  provided  by  l  isp.  I  bis  could  be  done  in  several 
ways,  f  irstly,  policies  could  be  expressed  ;cx  I  isp  (l.isp  Machine)  functions,  dispatching 
messages  to  objects  of  the  appropriate  flavor  and  wrappers;  the  programmer  would  have  to 
enumerate  till  the  flavor  mixes  required  by  the  policies.  This  achieves  dynamic  control  over 
over  method  execution  by  object  replication.  A  macio  technique  could  make  this  easier  to 
use.  Finally,  the  flavor  and  w  rapper  concepts  could  be  unified,  and  generalised  so  that  the 
policy  for  executing  methods  could  be  controlled  dynamically .  rather  than  being  tied  to  the 
order  in  which  flavors  are  combined. 

Two  significant  problems  need  immediate  consideration.  Firstly,  we  have  discussed  the 
formation  of  groups  from  classes  rather  than  objects,  and  the  difference  is  important  in 
languages  with  dynamic  process  creation.  Secondly,  we  have  not  examined  the  question  of 
objects  being  components  of  more  than  one  group  (shared  objects). 
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